When we log into a website or portal, we want to have accurate, cleansed data — our own data that’s personalized to us. This is especially true for B2B buyers dealing with manufacturers. In this context, personalization is critical and often a complex requirement to solve. It requires deep integration to SAP to ensure every B2B user gets an experience that’s driven by their unique SAP data and business rules.

In the world of SAP eCommerce, this gets tricky when the manufacturer has a customer with multiple sold-to’s that roll up to a single payer in SAP. How do you make sure the user with one sold-to sees only their own account information — not all the data for the high-level payer?  

One of our clients encountered this situation recently. Many SAP-integrated solutions would struggle to support this complexity, but Corevist’s architecture was flexible enough to solve this.

The problem: Multiple purchasing entities reporting to a single payer

Our client is a global manufacturer of industrial equipment. One of their larger customers has four purchasing locations around the US — east coast, west coast, north and south. All four regions roll up to a single paying group because their accounts payable department is centralized at the corporate level.

By default, when each of the four buyers logged on to our client’s portal, they each saw all open items for their payer number. For example, when the east coast buyer logged in and accessed open items (i.e. the invoices they need to pay off), they saw all open items from all regions governed by their payer number in SAP.

At the very least, this would lead to confusion, as the account balance is much larger than the buyer would expect. Things could get really messy if the buyer posted a payment against an open item associated with a different sold-to.

This is not the traditional setup, but it does happen. Typically, our clients’ customers have separate payer numbers for those unique geographical regions. Because of how Corevist is architected, each user would automatically see the right accounting information if their region had its own payer number.

Our client asked us if we could restrict financial visibility by sold-to. Luckily, we could!

Our solution: Filtered view driven by sold-to

We created a filter in Corevist Commerce Cloud to restrict the visibility of financial information by sold-to. Instead of showing all open items for the payer associated with the sold-to (which is our standard functionality), the filter looks at ship-to and sold-to on an item-by-item basis. It returns only the data associated with the buyer’s location for views like open items, search for invoices and pay invoices.

This wasn’t too difficult on our end, and our client was thrilled with the result. Now any customer of theirs with a single payer and multiple sold-tos can receive a filtered, personalized view of financial information straight from SAP ERP.  

Caveat: Transactions should post through SD, not FI

For this filtering to work, SAP has to be configured correctly.

In a nutshell, transactions need to post through the SD (sales and distribution) module, rather than direct FI (financial accounting) postings. When any transaction is posted in the FI module, you always post it against the payer number. If there’s a rebate, debit or credit posted against the payer directly in FI, it’s impossible to use that as a filter criterion (unless the clerk indicates who the sold-to is). You have no idea which sold-to that transaction applies to.

If those FI transactions run through SD, the filter works. The ship-to and sold-to information is preserved, which allows the filter to function.

Nine times out of ten, these transactions run through SD anyway. It’s standard procedure in the SAP world. But we do encounter outlying cases, and running it through SD isn’t the only way to pay off an open item. An SAP user with the correct permissions can go into the FI module and directly post a credit or debit against the payer.

In this scenario with multiple sold-tos, that creates a black box financial item. You can’t tell what sold-to it was associated with.

The takeaway: Follow SAP best practices and Corevist follows suit

Because Corevist is so deeply integrated into SAP ERP, the finer points of UX (user experience) in the portal often depend on SAP configuration. While it’s challenging to make SAP “customer-ready” in this way, it’s a great exercise because it forces you to bring your configuration closer to your actual business processes.

When you do that, you not only gain a better B2B portal experience — you also get a more harmonious data landscape with less technical debt accruing over time.